\section{Evaluatie}
Om het testen te vereenvoudigen is de mainloop geen oneindige lus, maar kunnen de testklassen de simulatie stap voor stap uitvoeren. Zie de bijlages voor een tabel met de testklassen en hun beschrijving.
\subsection{Wat getest}
Zoals bij de werkverdeling (zie sectie \ref{werkverdeling}) al vermeld is, is de code per iteratie op zijn werking getest. Deze testen konden dan herhaald worden indien in de andere iteratie iets mis liep. Zo vertonen de routes van de auto's geen lussen meer, gaan ze verder wanneer ze kunnen, nemen ze doordachte keuzes,...

Verder is er ook de performantie getest. De tijd die de auto's erover doet om een taak te vervullen wordt gemeten. Zo krijgen we een idee van de effici\"entie van de oplossing. Indien de oplossing intelligent genoeg is, worden alleen bij hoge verkeersdrukte auto's omgeleid.

De schaalbaarheid is getest om de hoeveelheid congestie te kunnen meten. Met meerdere auto's op hetzelfde wegennet stijgt de congestie. Het programma moet ervoor zorgen dat deze liefst zo laag mogelijk is. Ook hier testen we de effici\"entie van de code mee.

Tot slot is nog de flexibiliteit getest om het gedrag van het systeem waar te nemen in een veranderend wegennet. Zo kunnen we de reactie van het wegennet nakijken in een veranderende omgeving.
\subsection{Hoe getest}
Om het programma te testen is er een testopstelling gemaakt, die dan uitgevoerd wordt met een bepaald aantal auto's. De auto's krijgen allemaal een taak en een startpositie. De taak is volbracht wanneer ze op hun eindbestemming arriveren. Dan verdwijnen ze uit het systeem en worden weer toegevoegd door de test aan het systeem. De auto's verschijnen dan terug op hun startpositie vanaf het moment dat zich daar geen andere auto meer bevindt. Ze voeren dan opnieuw dezelfde taak uit.

De performantie wordt getest door de werkelijke tijd die de auto's nodig hebben om hun route af te leggen, te vergelijken met de kortst mogelijke tijd zonder verkeer. Indien een wagen zijn route kan afleggen in 23 tijdseenheden en de werkelijke tijd is 31 tijdseenheden dan is zijn performantie 31/23 = 1.348 . De performantie voor een auto kan dus nooit kleiner zijn dan 1, en is 1 indien hij zijn kortste route aflegt zonder ergens te moeten wachten. De performantie van een test is dan de gemiddelde performantie van alle auto's.

Voor de performantietesten zijn twee testopstellingen gebruikt. Deze opstellingen verschillen maar in twee straten. De tweede testopstelling heeft \'e\'en mogelijkheid meer om de bottleneck in het wegennet te vermijden, namelijk via deze twee straten. Deze test vergelijkt de performantie van het aantal exploration hops van de Exploration Ants.

De schaalbaarheid wordt dan getest door de test eerst te runnen met weinig congestie. Er zijn relatief gezien weinig auto's op de baan. Er treed weinig congestie op. Daarna wordt het aantal auto's verhoogd, en treedt er meer congestie op. Indien de congestie niet te hoog oploopt is de schaalbaarheid van ons programma goed.
\subsection{Metingen}
%Boekingen vervallen na 4 tijdseenheden.\\
%\begin{tabular}{lll}
%Aantal auto's   & Aantal tijdseenheden & Performantie\\
%13 & 500 & 1.013\\
%13 & 1500 & 1.012\\
%29 & 100 & 1.180\\
%29 & 500 & 1.172\\
%29 & 1500 & 1.165\\
%\end{tabular}

%na acties aan te passen, boekingen vervallen na 2 tijdseenheden\\
%\begin{tabular}{lllll}
%Auto's   & tijd & exploratie hopq & deadlock & Performantie\\
%13 & 500 & 7 & no &1.013\\
%29 & 500 & 3 & no & 1.105\\
%29 & 500 & 4 & no & 1.131\\
%29 & 500 & 5 & no & 1.190\\
%29 & 500 & 5 & on & 1.128\\
%29 & 500 & 7 & no & 1.416\\
%29 & 1500 &  3? & no &1.155 \\
%\end{tabular}
In onderstaande tabel zijn de performantietesten weergegeven voor 13 auto's. Het wegennet is nu voor 17\% bezet door auto's.\\
\\
\begin{tabular}{llllll}
Aantal auto's   & Aantal  & Exploratie & Deadlock & Boeking&Performantie\\
 & tijdseenheden&grootte &&vervaltijd&\\
\hline
13 & 500 & 3 &nee &2& 1.0135\\
13 & 500 & 5 &nee &2& 1.0131\\
\end{tabular}
\\
\\
Doordat er weinig auto's zijn, is er weinig congestie en kan het verschil tussen 3 en 5 hops bij de Exploration Ants verwaarloosd worden.\\
\\
%na aanpassen vogelvlucht en traffic\\
In onderstaande tabel zijn de performantietesten weergegeven voor 29 wagens. Het wegennet is nu voor 39\% bezet met auto's. Er zal dus meer congestie optreden.\\
\\
\begin{tabular}{llllll}
Aantal auto's   & Aantal  & Exploratie& Deadlock & Boeking &Performantie\\
 &tijdseenheden&grootte&&vervaltijd&\\
\hline
29 & 500 & 3 &nee &2& 1.117\\
%29 & 500 & 4& no &2& 1.175\\ met 4 slechter, met 5 terug beter
%29 & 500 & 4& no &2&1.234\\
29 & 500 & 5 &nee &2 &1.108\\
29 & 500 & 5 &ja &2 &1.199\\
29 & 500 & 5 &nee & 4 &1.271\\
\end{tabular}
\\
\\
De code zonder deadlockdetectie is duidelijk beter. Deadlock betekent dat de auto drie keer een weg geboekt heeft en altijd verhinderd werd om deze te betreden. De auto gaat daarna geen route meer boeken met deze resource in zijn planning. Deze gevallen worden opgelost door de Exploration Ants indien er geen deadlockdetectie is. Het pad wordt onrechtmatig geblokkeerd en kan terug vrijkomen. De deadlockdetectie werd in een vroege iteratie toegevoegd om deadlock te vermijden. Nadien is de code gewijzigd waardoor deadlocks onwaarschijnlijk werden.

Dezelfde testopstelling werd opnieuw gebruikt, maar met twee nieuwe wegen om de bottleneck te vermijden. De meetresultaten worden in onderstaande tabel weergegeven.\\
\\
\begin{tabular}{llllll}
Aantal auto's   & Aantal  & Exploratie & Deadlock & Boekings&Performantie\\
&tijdseenheden &grootte & &vervaltijd&\\
\hline
29 & 500 & 3 &nee &2& 1.113\\
%29 & 500 & 4& no &2& 1.175\\ met 4 slechter, met 5 terug beter
%29 & 500 & 4& no &2&1.234\\
29 & 1500 & 3 &ja &2 &1.121\\
29 & 500 & 5 &nee & 2 &1.101\\
29 & 1500 & 5 &nee &2 &1.107\\
\end{tabular}
\\
%De performantie met 29 auto's terwijl de test 1500 tijdseenheden duurde, is 1.208. Dit terwijl de boekingen vervielen na 2 tijdseenheden.oude %restulaten?
\\
Deze resultaten zijn iets beter dan de vorige. Indien nodig sturen de Task Agents hun auto's over alternatieve routes, wat ook de bedoeling is. Er zit wel een kleine variatie op de performantie, vandaar het verschil in performantie naar gelang de tijdseenheden. Ondanks dat geeft de oplossing met 5 hops toch betere resultaten.\\
\\
De startopstelling van de flexibiteitstest wordt weergegeven in figuur \ref{fig:flex}. Na enkele tijdseenheden valt de weg van c7 naar c8 weg. De auto's nemen dan niet meer deze weg en het systeem past zichzelf aan. Daarna valt kruispunt c8 weg en opnieuw kiezen de auto's een andere weg en laten ze deze wegvallen.

\subsection{Discussie}
De keuze van de constanten in het programma hebben een grote invloed op de performantie. Hoe groter de vervaltijd van boekingen, des te minder flexibel het systeem wordt t.o.v. keuzeveranderingen van de Task Agents. Indien de vervaltijd van de boekingen groter is dan de periode waarover de auto's vooruit boeken, zal de boeking te laat vervallen. Auto's zullen dan blijven wachten op niets. Of anders geformuleerd, de tijd vooraleer een boeking vervalt moet lang genoeg zijn opdat een auto zijn boeking zou kunnen hernieuwen, maar kort genoeg om het verkeer niet te hinderen bij de keuze van een andere route.\\
\\
In het programma hebben de Exploration Ants een maximale hopcount. Dit kan soms voor een vertekend beeld zorgen van de verkende weg. Omdat routes met veel korte resources minder ver verkend worden, dan routes die uit lange resources bestaan. De uiteindelijke schatting van de nog af te leggen weg, is nauwkeuriger in dit laatste geval (er is immers verder verkend). Welke route dan gekozen wordt hangt dan sterk af van de constante van de penalties. Terwijl dit niet het geval is wanneer de Exploration Ants verkennen tot op een zekere afstand in plaats van hopcount. Het zou interessant zijn om ook deze mogelijkheid te onderzoeken.\\
\\
Ook bij de Intention Ants ontstaat dit probleem. De auto's op een langere weg kunnen een langere trip boeken, m.a.w. hun resources reserveren. Zij hebben dus 'voorrang' op een auto dichter in de buurt maar met meer resources tussen. Communicatie tussen de agents zou dit probleem dan kunnen oplossen door voorrang te geven aan de langst wachtende.
\\
\\
De performantie kan misschien nog scherper worden, maar door de complexiteit van het probleem wordt dit al redelijk moeilijk. De laatste beslissingsfouten van Task Agents die uit het programma gehaald werden, ontstonden nu al 4 tijdseenheden voordat de fout optrad. De auto bleef wachten wanneer het niet nodig was. De oorzaak van een verkeerde boeking is in deze gevallen niet altijd even duidelijk.\\
\\
De communicatie in het systeem gebeurt nu zeer frequent. Elke beurt worden er Exploration en Intention Ants verstuurd. Het systeem zou het ook aankunnen indien er een paar beurten geen verstuurd worden of indien ze verstuurd worden met onregelmatige intervallen. De enige voorwaarde hiervoor is dat de boekingen dan traag genoeg vervallen. Een auto moet zijn boeking kunnen vernieuwen, deze mag niet vervallen voordat hij ze kan vernieuwen.\\
\\
De frequentie van Feasibility Ants wordt nu al beperkt, maar zou nog verder beperkt kunnen worden. Wanneer de resource agents op verschillende momenten hun ants zullen zenden zullen er ook minder Feasibility Ants verstuurd worden maar blijft dezelfde performantie behouden. Omdat dit nu in discrete tijdsintervallen gebeurt, worden de Feasibility Ants allemaal op hetzelfde tijdstip verstuurd.